Internet Engineering Task Force (IETF) J. Abley 


Request for Comments: 7534 Dyn, Inc. 
Obsoletes: 6304 W. Sotomayor 
Category: Informational Ott IX 
ISSN: 2070-1721 May 2015 


AS112 Nameserver Operations 
Abstract 
Many sites connected to the Internet make use of IPv4 addresses that 


are not globally unique. Examples are the addresses designated in 
RFC 1918 for private use within individual sites. 


Devices in such environments may occasionally originate Domain Name 
System (DNS) queries (so-called "reverse lookups") corresponding to 
those private-use addresses. Since the addresses concerned have only 
local significance, it is good practice for site administrators to 
ensure that such queries are answered locally. However, it is not 
uncommon for such queries to follow the normal delegation path in the 
public DNS instead of being answered within the site. 


It is not possible for public DNS servers to give useful answers to 
such queries. In addition, due to the wide deployment of private-use 
addresses and the continuing growth of the Internet, the volume of 
such queries is large and growing. The AS112 project aims to provide 
a distributed sink for such queries in order to reduce the load on 
the corresponding authoritative servers. The AS112 project is named 
after the Autonomous System Number (ASN) that was assigned to it. 


This document describes the steps required to install a new AS112 
node and offers advice relating to such a node's operation. 


This document obsoletes RFC 6304. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7534. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Many sites connected to the Internet make use of IPv4 addresses that 
are not globally unique. Examples are the addresses designated in 
[RFC1918] for private use within individual sites. 


Devices in such environments may occasionally originate Domain Name 
System (DNS) [RFC1034] queries (so-called "reverse lookups") 
corresponding to those private-use addresses. Since the addresses 
concerned have only local significance, it is good practice for site 
administrators to ensure that such queries are answered locally 
[RFC6303]. However, it is not uncommon for such queries to follow 
the normal delegation path in the public DNS instead of being 
answered within the site. 


It is not possible for public DNS servers to give useful answers to 
such queries. In addition, due to the wide deployment of private-use 
addresses and the continuing growth of the Internet, the volume of 
such queries is large and growing. The AS112 project aims to provide 
a distributed sink for such queries in order to reduce the load on 
the IN-ADDR.ARPA authoritative servers [RFC5855]. 


The As112 project encompasses a loosely coordinated collection of 
independently operated nameservers. Each nameserver functions as a 
single node in an AS112 anycast cloud [RFC4786] and is configured to 
answer authoritatively for a particular set of nominated zones. 


The AS112 project is named after the Autonomous System Number (ASN) 
that was assigned to it (see Appendix A). 


2. AS112 DNS Service 

2.1. Approach 

2.1.1. Direct Delegation 
The AS112 project currently uses an approach whereby zones whose 
traffic should be directed towards an AS112 sink should be directly 
delegated to AS112 nameservers. Correspondingly, each AS112 node is 
manually configured to answer appropriately for those zones. 
The guidance in this document describes this capability for the zones 
that were originally delegated in this fashion. AS112 nodes that 


were implemented in accordance with the guidance found here will 
continue to provide service for those zones. 
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2.1.2. DNAME Redirection 
[RFC7535] describes a different approach whereby queries towards 
specific zones are redirected to an empty zone also hosted on AS112 
servers, using DNAME [RFC6672]. 
The guidance in this document introduces this capability, allowing 
any zone administrator to sink query traffic in AS112 infrastructure 
without requiring changes to any AS112 node. 

2.2. Zones 
To support Direct Delegation AS112 service, AS112 nameservers answer 
authoritatively for the following zones, corresponding to [RFC1918] 
private-use netblocks: 
o 10.IN-ADDR.ARPA 
o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA 
o 168.192.IN-ADDR.ARPA 


and the following zone, corresponding to the "link local" netblock 
169.254.0.0/16 listed in [RFC6890]: 


o 254.169.IN-ADDR.ARPA 


To support DNAME redirection AS112 service, AS112 nameservers answer 
authoritatively for the following zone, as specified in [RFC7535]: 


o EMPTY.AS112.ARPA 


To aid identification of AS112 anycast nodes, each node also answers 
authoritatively for the following zones: 


o HOSTNAME.AS112.NET 


o HOSTNAME.AS112.ARPA 


See Section 3.5 for the recommended contents of all these zones. 
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2.3. Nameservers 


To support Direct Delegation AS112 service, the relevant zones listed 
in Section 2.2 are delegated to the two nameservers 
BLACKHOLE-1.IANA.ORG (192.175.48.6, 2620:4f:8000::6) and 
BLACKHOLE-2.IANA.ORG (192.175.48.42, 2620:4f:8000::42). 


Additionally, the server PRISONER.IANA.ORG (192.175.48.1, 
2620:4f:8000::1) is listed in the MNAME field of the SOA records of 
the IN-ADDR.ARPA zones served by AS112 nameservers. 
PRISONER.IANA.ORG receives mainly dynamic update queries. 


The addresses of all these nameservers are covered by the single IPv4 
prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48. To 
date, IPv6 transport for these nameservers has only been available 
for pre-production testing. IANA has added AAAA RRSets for the owner 
names of these nameservers; see Section 7. 


To support DNAME redirection AS112 service, the single zone 
EMPTY.AS112.ARPA is delegated to the single nameserver 
BLACKHOLE.AS112.ARPA (192.31.196.1, 2001:4:112::1). The addresses of 
that nameserver are covered by the single IPv4 prefix 192.31.196.0/24 
and the single IPv6 prefix 2001:4:112::/48. 

3. Installation of a New Node 


3.1. Useful Background Knowledge 


Installation of an AS112 node is relatively straightforward. 
However, experience in the following general areas may prove useful: 


o inter-domain routing with BGP [RFC4271]; 
o DNS authoritative server operations; and 
o anycast [RFC4786] distribution of DNS services. 

3.2. Topological Location 
AS112 nodes may be located anywhere on the Internet. For nodes that 
are intended to provide a public service to the Internet community 
(as opposed to private use), it may well be advantageous to choose a 


location that is easily (and cheaply) reachable by multiple 
providers, such as an Internet Exchange Point. 
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AS112 nodes may advertise their service prefix to BGP peers for local 
use (analogous to a conventional peering relationship between two 
providers) or for global use (analogous to a customer relationship 
with one or more providers). 


It is good operational practice to notify the community of users that 
may fall within the reach of a new AS112 node before it is installed. 
At an Internet Exchange, local mailing lists usually exist to 
facilitate such announcements. For nodes that are intended to be 
globally reachable, coordination with other AS112 operators is highly 
recommended. See also Section 5. 


3.3. Operating System and Host Considerations 


Examples in this document are based on UNIX and UNIX-like operating 
systems, but other operating systems exist that are suitable for use 
in construction of an AS112 node. 


The chosen platform should include either support for cloned loopback 
interfaces or the capability to bind multiple addresses to a single 
loopback interface. The addresses of the nameservers listed in 
Section 2.3 will be configured on these interfaces in order that the 
DNS software can respond to queries properly. 


A host that is configured to act as an AS112 anycast node should be 
dedicated to that purpose and should not be used to simultaneously 
provide other services. This guidance is provided due to the 
unpredictable (and occasionally high) traffic levels that AS112 nodes 
have been seen to attract. 


System startup scripts should be arranged such that the various 
AS112-related components start automatically following a system 
reboot. The order in which interfaces are configured and software 
components started should be arranged such that routing software 
startup follows DNS software startup, and DNS software startup 
follows loopback interface configuration. 


Wrapper scripts or other arrangements should be employed to ensure 
that the anycast service prefix for AS112 is not advertised while 
either the anycast addresses are not configured or the DNS software 
is not running. 


3.4. Routing Software 


AS112 nodes signal the availability of AS112 nameservers to the 
Internet using BGP [RFC4271]: each AS112 node is a BGP speaker and 
announces the prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to the 
Internet with origin AS 112 (see also Section 2.3). 
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The examples in this document are based on the Quagga Routing Suite 
<http://www.quagga.net> running on Linux, but other software packages 
exist that also provide suitable BGP support for AS112 nodes. 


The "bgpd.conf" file is used by Quagga’s bgpd daemon, which provides 
BGP support. The router ID in this example is 203.0.113.1; the AS112 
node peers with external peers 192.0.2.1, 192.0.2.2, 2001:db8::1, and 
2001:db8::2. Note that the local AS number is 112, and the service 
prefixes originated from the AS112 node to support Direct Delegation 
service are 192.175.48.0/24 and 2620:4f:8000::/48; the IPv4 prefix 
192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48 support DNAME 
redirection. 


For clarity, an IPv4-only AS112 node need not configure any of the 
IPv6 elements that follow; similarly, an IPv6-only AS112 node need 
not configure any of the IPv4 elements. Such single-stack hosts can 
still contribute usefully to IPv4 and IPv6 AS112 services, however, 
and single-stack operation is not discouraged. 


! bgpd.conf 

| 

hostname as112-bgpd 

password <something> 

enable password <supersomething> 

! 
Note that all AS112 nodes use the local Autonomous System Number 
112, and originate the IPv4 prefixes 192.175.48.0/24 and 
192.31.196.0/24 and the IPv6 prefixes 2620:4f:8000::/48 and 
2001:4:112::/48. 


actual numbers will depend on local circumstances. 


f 

l 

l 

l 

! 

! All other addresses shown below are illustrative, and 
l 

! 

! IPv4-only or IPv6-only AS112 nodes should omit advertisements 
! for address families they do not support. 

l 

router bgp 112 

bgp router-id 203.0.113.1 


neighbor 192.0.2.1 remote-as 64496 

neighbor 192.0.2.1 next-hop-self 

neighbor 192.0.2.1 prefix-list AS112-v4 out 
neighbor 192.0.2.1 filter-list 1 out 

l 

neighbor 192.0.2.2 remote-as 64497 

neighbor 192.0.2.2 next-hop-self 

neighbor 192.0.2.2 prefix-list AS112-v4 out 
neighbor 192.0.2.2 filter-list 1 out 
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neighbor 2001:db8::1 remote-as 64498 

neighbor 2001:db8::1 next-hop-self 

neighbor 2001:db8::1 prefix-list AS112-v6 out 
neighbor 2001:db8::1 filter-list 1 out 

l 

neighbor 2001:db8::2 remote-as 64499 

neighbor 2001:db8::2 next-hop-self 

neighbor 2001:db8::2 prefix-list AS112-v6 out 
neighbor 2001:db8::2 filter-list 1 out 


network 192.175.48.0/24 
network 192.31.196.0/24 
| 
address-family ipv6 unicast 
network 2620:4f:8000::/48 
network 2001:4:112::/48 
exit-address-family 
| 
ip prefix-list AS112-v4 permit 192.175.48.0/24 
ip prefix-list AS112-v4 permit 192.31.196.0/24 
! 


ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48 
ipv6 prefix-list AS112-v6 permit 2001:4:112::/48 
1 


ip as-path access-list 1 permit ^$ 


The configuration above includes two restrictions on what the AS112 
should advertise to its BGP neighbours: a prefix filter that permits 
only the service prefixes, and an AS_PATH filter that matches only 
locally originated routes. Together, these measures prevent the node 
from becoming a transit point for its adjacent ASes. 


The "zebra.conf" file is required to provide integration between 
protocol daemons (bgpd, in this case) and the kernel. 


! zebra.conf 
l 
hostname as112 
password <something> 
enable password <supersomething> 
l 
interface lo 
l 


interface eth0 
f 
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3.5. DNS Software 


Although the queries received by AS112 nodes are definitively 
misdirected, it is important that they be answered in a manner that 
is accurate and consistent. For this reason, AS112 nodes operate as 
fully functional and standards-compliant DNS authoritative servers 
[RFC1034], and hence require appropriate DNS software. 


Examples in this document are based on ISC BIND9 
<http://www.isc.org/software/BIND/>, but other DNS software exists 
that is suitable for use in construction of an AS112 node. 


The following is a sample BIND9 "named.conf" file for a dedicated 
AS112 server. Note that the nameserver is configured to act as an 
authoritative-only server (i.e., recursion is disabled). The 
nameserver is also configured to listen on the various AS112 anycast 
nameserver addresses, as well as its local addresses. 


A basic logging example is included in the sample as well. AS112 
operators may exercise discretion at the amount of logging detail 
they desire or the type of logging they may use in the maintenance of 
their node. The detail of information can then be used to single out 
bad implementors or badly managed nameservers, or it can be used for 
simple measurement analysis. 


// named.conf 

// Global options 

options { 
listen-on { 


127008 17 // localhost 


// The following address is node-dependent and should be set to 
// something appropriate for the new AS112 node. 


20370011315 // local address (globally unique, unicast) 


// The following addresses are used to support Direct Delegation 
// AS112 service and are the same for all AS112 nodes. 


192.175.48.1; // prisoner.iana.org (anycast) 
192.175.48.6; // blackhole-l.iana.org (anycast) 
192.175.48.42; // blackhole-2.iana.org (anycast) 
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// The following address is used to support DNAME redirection 
// AS112 service and is the same for all AS112 nodes. 


192.31.196.1; // blackhole.as112.arpa (anycast) 
y; 


listen-on-v6 { 
:1; // localhost 


// The following addresses are used to support Direct Delegation 
// AS112 service and are the same for all AS112 nodes. 


2620:4f:8000::1; // prisoner.iana.org (anycast) 
2620:4f:8000::6; // blackhole-1.iana.org (anycast) 
2620:4f:8000::42; // blackhole-2.iana.org (anycast) 


// The following address is used to support DNAME redirection 
// AS112 service and is the same for all AS112 nodes. 


2001:4:112::1; // blackhole.as112.arpa (anycast) 
y; 


directory "/var/named"; 
recursion no; // authoritative-only server 


// Log queries, so that when people call us about unexpected 

// answers to queries they didn't realise they had sent, we 

// have something to talk about. Note that activating this 

// naively has the potential to create high CPU load and consume 
// enormous amounts of disk space. This example retains 2 old 
// versions at a maximum of 500 MB each before rotating out the 
// oldest one. 


logging ( 
channel "querylog" { 
file "/var/log/query.log" versions 2 size 500m; 
print-time yes; 
y; 
category queries { querylog; }; 
y; 
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// Direct Delegation AS112 Service 


// REC 1918 


zone "10. 
zone "16.172. 
zone "17.172 
zone "18.172. 
zone "19.172. 
zone "20.172. 
zone "21.172 
zone "22.172. 
zone "23.172. 
zone "24.172 
zone "25.172. 
zone "26.172. 
zone "27.172. 
zone "28.172 
zone "29.172. 
zone "30.172. 
zone "31.172 
zone 

// REC 6890 


zone "254.169.in-addr.arpa" 
// DNAME redirection AS112 Service 


zone “empty.as112.arpa" 


in-addr.arpa" 
in-addr. 
.in-addr. 
in-addr. 
in-addr. 
in-addr. 
-in-addr. 
in-addr. 
in-addr. 
.in-addr. 
in-addr. 
in-addr. 
in-addr. 
.in-addr. 
in-addr. 
in-addr. 
.in-addr. 
"168.192.in-addr.arpa" 
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arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 
arpa" 


{ 


Pa A A As A A A A Ass ss ss ss o a 


{ type master; 


type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 
type 


{ type master; 


master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 
master; 


{ type master; 


{ type master; 


file 


file 


"db. 


file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 
file 


file 


file 


May 2015 


dd-empty"; }; 


" db 


" db 
"db 


" db 


" db 
" db 


" db 


.Ad-empty"; ); 
"db. 
"db. 


dd-empty"; }; 
dd-empty"; }; 


.Ad-empty"; ); 
.Ad-empty"; ); 
"db: 
"db. 


dd-empty"; }; 
dd-empty"; }; 


.Ad-empty"; ); 
"db. 
"db. 


dd-empty"; }; 
dd-empty"; }; 


-dd-empty"; }; 
-dd-empty"; }; 
"db. 
"db. 


dd-empty"; }; 
dd-empty"; }; 


.Ad-empty"; }; 
"dab. 


dd-empty"; }; 


"db.dd-empty"; }; 


"db.dd-empty"; }; 


"db.dr-empty"; }; 


// Also answer authoritatively for the HOSTNAME.AS112.NET and 
which contain data of operational 


// HOSTNAME.AS112.ARPA zones, 
// relevance. 


zone 


file 


y; 


"hostname.as112.net" 
type master; 


zone "hostname.as112.arpa" 
type master; 
file "db.hostname.as112.arpa"; 


y; 
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The "db.dd-empty" file follows, below. This is the source data used 
to populate all the IN-ADDR.ARPA zones listed in Section 2.2 that 
support Direct Delegation AS112 service. Note that the RNAME 
specified in the SOA record corresponds to 
hostmaster@root-—servers.org, a suitable email address for receiving 
technical queries about these zones. 


; db.dd-empty 


; Empty zone for Direct Delegation AS112 service. 


7 
STTL 1W 


@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. ( 
1 ; serial number 
1W ; refresh 
1M ; retry 
1W ; expire 
1W ) ; negative caching TTL 
r 
NS blackhole-1.iana.org. 
NS blackhole-2.iana.org. 


; There should be no other resource records included in this zone. 


; Records that relate to RFC 1918-numbered resources within the 
; site hosting this AS112 node should not be hosted on this 
; nameserver. 


The "db.dr-empty" file follows, below. This is the source data used 
to populate the EMPTY.AS112.ARPA zone that supports DNAME redirection 
AS112 service. Note that the RNAME specified in the SOA record 
corresponds to noc@dns.icann.org, a suitable email address for 
technical queries about this zone. 


; db.dr-empty 


; Empty zone for DNAME redirection AS112 service. 


1 
STTL 1W 


@ IN SOA blackhole.as112.arpa. noc.dns.icann.org. ( 
1 ; serial number 
1W ; refresh 
1M ; retry 
1W ; expire 
1W ) ; negative caching TTL 
1 
NS blackhole.as112.arpa. 
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; There should be no other resource records included in this zone. 


; Records that relate to RFC 1918-numbered resources within the 
; site hosting this AS112 node should not be hosted on this 
; nameserver. 


The "db.hostname.as112.net" and "db.hostname.as112.arpa" files 
follow, below. These zones contain various resource records that 
provide operational data to users for troubleshooting or measurement 
purposes; the data should be edited to suit local circumstances. 

Note that the responses to the queries "HOSTNAME.AS112.NET IN TXT" 
and "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512-octet DNS/ 
UDP datagram: i.e., it should be available over UDP transport without 
requiring EDNSO support by the client. 


The optional LOC record [RFC1876] included in each zone apex provides 
information about the geospatial location of the node. 


Where software implementations support it, operational data should 
also be carried using NSID [RFC5001]. 


; db.hostname.as112.net 


7 
STTL 1W 


@ SOA server.example.net. admin.example.net. ( 
1 ; serial number 
1W ; refresh 
1M ; retry 
1W ; expire 
1W ) ; negative caching TTL 
i 
NS blackhole-1.iana.org. 
NS blackhole-2.iana.org. 
i 
TXT "Name of Facility or similar" "City, Country" 
TXT "See http://www.as112.net/ for more information." 
TXT "Unique IP: 203.0.113.1." 
i 
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 
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; db.hostname.as112.arpa 


r 
STTL 1W 


@ SOA server.example.net. admin.example.net. ( 
1 ; serial number 
1W ; refresh 
1M ; retry 
1W ; expire 
1W ) ; negative caching TTL 
i 
NS blackhole.as112.arpa. 
i 
TXT "Name of Facility or similar" "City, Country" 
TXT "See http://www.as112.net/ for more information." 
i 
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 


3.6. Testing a Newly Installed Node 


The BIND9 tool "dig" can be used to retrieve the TXT resource records 
associated with the names "HOSTNAME.AS112.NET" and 
"HOSTNAME.AS112.ARPA", directed at one of the AS112 anycast 


nameserver addresses. Continuing the example from above, the 
response received should indicate the identity of the AS112 node that 
responded to the query. See Section 3.5 for more details about the 


resource records associated with "HOSTNAME.AS112.NET". 

$ dig @prisoner.iana.org hostname.as112.net txt +short +norec 
"Name of Facility or similar" "City, Country" 
"See http://www.as112.net/ for more information." 


o 
5 


If the response received indicates that a different node is being 
used, then there is probably a routing problem to solve. If there is 
no response received at all, there might be a host or nameserver 
problem. Judicious use of tools such as traceroute and consultation 
of BGP looking glasses might be useful in troubleshooting. 


Note that an appropriate set of tests for a new server will include 
queries sent from many different places within the expected service 
area of the node, using both UDP and TCP transport, and exercising 
all three AS112 anycast nameserver addresses. 
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4. Operations 
4.1. Monitoring 


AS112 nodes should be monitored to ensure that they are functioning 
correctly, just as with any other production service. An AS112 node 
that stops answering queries correctly can cause failures and 
timeouts in unexpected places and can lead to failures in dependent 
systems that can be difficult to troubleshoot. 


4.2. Downtime 


An AS112 node that needs to go off-line (e.g., for planned 
maintenance or as part of the diagnosis of some problem) should stop 
advertising the AS112 service prefixes to its BGP peers. This can be 
done by shutting down the routing software on the node altogether or 
by causing the routing system to withdraw the route. 


Withdrawing the service prefixes is important in order to avoid 
blackholing query traffic in the event that the DNS software on the 
node is not functioning normally. 


4.3. Statistics and Measurement 
Use of the AS112 node should be measured in order to track long-term 
trends, identify anomalous conditions, and ensure that the 
configuration of the AS112 node is sufficient to handle the query 


load. 


Examples of free monitoring tools that might be useful to operators 
of AS112 nodes include: 


o bindgraph <http://www.linux.it/~md/software/> 

o dnstop <http://dns.measurement-factory.com/tools/dnstop/> 

o DSC <https://www.dns-oarc.net/tools/dsc/> 

Operators of AS112 nodes should also consider participating in 
collection events as part of a larger, coordinated effort to gather 
important baselines. One example of such an effort is Day in the 


Life <https://www.dns-oarc.net/oarc/data/ditl/>, coordinated by the 
DNS-OARC <https://www.dns-oarc.net/>. 
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5. 


Communications 


It is good operational practice to notify the community of users that 
may fall within the reach of a new AS112 node before it is installed. 
At Internet Exchanges, local mailing lists usually exist to 
facilitate such announcements. 


For nodes that are intended to be globally reachable, coordination 
with other AS112 operators is especially recommended. The mailing 
list <as112-opstlists.dns-oarc.net> is operated for this purpose. 


Information pertinent to AS112 operations is maintained at 
<http://www.as112.net/>. 


Information about an AS112 node should also be published within the 
DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. 
See Section 3.5 for more details. 


AS112 operators should also be aware of the measures described in 
[RFC6305] and direct site administrators appropriately. 


On the Future of AS112 Nodes 


It is recommended practice for the operators of recursive nameservers 
to answer queries for zones served by AS112 nodes locally, such that 
queries never have an opportunity to reach AS112 servers [RFC6303]. 
Operational experience with AS112 nodes does not currently indicate 
an observable trend towards compliance with those recommendations, 
however. 


It is expected that some DNS software vendors will include default 
configuration that will implement measures such as those described in 
[RFC6303]. If such software is widely deployed, it is reasonable to 
assume that the query load received by AS112 nodes will decrease; 
however, it is safe to assume that the query load will not decrease 
to zero, and consequently that AS112 nodes will continue to provide a 
useful service for the foreseeable future. 


The use of DNAME redirection to provide AS112 service is new and 
hence is informed by minimal operational experience. The use of 
DNAME means that queries for many source zones could be redirected to 
AS112 infrastructure with no real opportunity for coordination. 


If the DNAME redirection approach is successful, and in the absence 
of any operational concerns, the community might well recommend the 
retirement of the original Direct Delegation AS112 service. This 
document makes no such recommendation, however. 
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7. IANA Considerations 
7.1. General 


The nameservers associated with Direct Delegation AS112 service are 

all named under the domain IANA.ORG (see Section 2.3). However, the 
anycast infrastructure itself is operated by a loosely coordinated, 

diverse mix of organisations across the Internet and is not an IANA 
function. 


The autonomous system number 112, the IPv4 prefix 192.175.48.0/24, 
and the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN. 


The IPv4 prefix 192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48, 
used for DNAME redirection AS112 service, were assigned by the IANA 
[RFC7535]. 


The three nameservers BLACKHOLE-1.IANA.ORG, BLACKHOLE-2.IANA.ORG, and 
PRISONER.IANA.ORG are also reachable over IPv6, as described in 
Section 2.3. Following a substantial period of pre-production 
testing by AS112 operators, the IANA has added AAAA RRSets to those 
owner names in Section 7.2.1, to allow the servers to receive queries 
and generate responses over IPv6 transport. 


7.2. IANA Actions 
7.2.1. IPv6 Transport for Direct Delegation AS112 Servers 


The IANA has added the following AAAA resource records for the three 
Direct Delegation AS112 nameservers named under IANA.ORG: 


4---------------------- 4+------------------ + 
| Owner Name | AAAA RDATA 

4+---------------------- 4+------------------ + 
| PRISONER. IANA.ORG | 2620:4f£:8000::1 | 
| | | 
| BLACKHOLE-1.IANA.ORG | 2620:4f£:8000::6 | 
| | | 
| BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 | 
4+---------------------- 4+------------------ + 
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7.2.2. Registration in the Special-Purpose AS Numbers Registry 


The IANA has added AS112 to the "Special-Purpose AS Numbers" registry 
specified in [RFC7249] as follows: 


AS Numbers: 112 


Reason for Reservation: Used by the AS112 project to sink 
misdirected DNS queries; see RFC 7534. 


7.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry 


The IANA has added 192.175.48.0/24 to the "IANA IPv4 Special-Purpose 
Address Registry" specified in [RFC6890] as follows: 


Address Block: 192.175.48.0/24 
Name: Direct Delegation AS112 Service 
RFC: RFC 7534 
Allocation Date: 1996-01 
Termination Date: N/A 
Source: True 
Destination: True 
Forwardable: True 
Global: True 
Reserved-by-Protocol: False 
7.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry 


The IANA has added 2620:4f:8000::/48 to the "IANA IPv6 Special- 
Purpose Address Registry" specified in [RFC6890] as follows: 


Address Block: 2620:4f£:8000::/48 
Name: Direct Delegation AS112 Service 
RFC: RFC 7534 


Allocation Date: 2011-05 
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Termination Date: N/A 

Source: True 

Destination: True 

Forwardable: True 

Global: True 

Reserved-by-Protocol: False 
8. Security Considerations 


Hosts should never normally send queries to AS112 servers; queries 
relating to private-use addresses should be answered locally within a 
site. Hosts that send queries to AS112 servers may well leak 
information relating to private infrastructure to the public network, 
and this could present a security risk. Additionally, AS112 
operators may log this information, making it further subject to 
whatever security and privacy risks that might entail. These risks 
are orthogonal to the presence or absence of authoritative servers 
for these zones in the public DNS infrastructure, however. 


Queries that are answered by AS112 servers are usually unintentional; 
it follows that the responses from AS112 servers are usually 
unexpected. Unexpected inbound traffic can trigger intrusion 
detection systems or alerts by firewalls. Operators of AS112 servers 
should be prepared to be contacted by operators of remote 
infrastructure who believe their security has been violated. Advice 
to those who mistakenly believe that responses from AS112 nodes 
constitute an attack on their infrastructure can be found in 
[RFC6305]. 


The deployment of AS112 nodes is very loosely coordinated compared to 
other services distributed using anycast. The malicious compromise 
of an AS112 node and subversion of the data served by the node are 
hence more difficult to detect due to the lack of central management. 
Since it is conceivable that changing the responses to queries 
received by AS112 nodes might influence the behaviour of the hosts 
sending the queries, such a compromise might be used as an attack 
vector against private infrastructure. 


Operators of AS112 should take appropriate measures to ensure that 
AS112 nodes are appropriately protected from compromise, such as 
would normally be employed for production nameserver or network 
infrastructure. The guidance provided for root nameservers in 
[RFC2870] may be instructive. 
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The zones hosted by AS112 servers are not signed with DNSSEC 
[RFC4033]. Given the distributed and loosely coordinated structure 
of the AS112 service, the zones concerned could only be signed if the 
private key material used was effectively public, obviating any 
security benefit resulting from the use of those keys. 
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Appendix A. A Brief History of AS112 


Widespread use of the private address blocks listed in [RFC1918] 
followed that document’s publication in 1996. At that time, the 
IN-ADDR.ARPA zone was served by root servers. 


The idea of offloading IN-ADDR.ARPA queries relating to [RFC1918] 
addresses from the root nameservers was first proposed by Bill 
Manning and John Brown. 


The use of anycast for distributing authoritative DNS service for 
[RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private 
meeting of root server operators. 


ARIN provided an IPv4 prefix for the anycast service and also the 
autonomous system number 112 for use in originating that prefix. 
This assignment gave the project its name. 


In 2002, the first AS112 anycast nodes were deployed. 


In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers 
to a new set of servers operated independently by AfriNIC, APNIC, 
ARIN, ICANN, LACNIC, and the RIPE NCC and named according to 
[RFC5855]. 


[RFC6304], the precursor to this document, was published in 
July 2011. 


The use of anycast nameservers in the AS112 project contributed to 
the operational experience of anycast DNS services, and it can be 
seen as a precursor to the anycast distribution of other 
authoritative DNS servers in subsequent years (e.g., various root 
servers). 


Appendix B. Changes since RFC 6304 


A number of changes and enhancements to the AS112 service has been 
introduced since the publication of [RFC6304]. 


o The addition of IPv6 transport. 
o The extension of the AS112 service to include the ability to have 
additional zones delegated for sinking or removed using the DNAME 


resource record. 


o Requisite changes to the guidance regarding the configuration of 
current and future AS112 nodes. 
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o Further clarification about the leakage of information in the 
Security Considerations section. 


o A direction to the IANA to register the AS112 project’s prefixes 
in the IANA Special-Purpose Address registries. 
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